rofiles-fuse: Support breaking hardlinks to fs-verity files #3174
Conversation
In case fs-verity is in used for the repo objects, and something like "rpm-ostree apply-live" uses rofiles-fuse with --copyup, then writing to a hard-linked file fails to copy up, like this: echo foo > /a/rofile-mnt/a-file /a/rofile-mnt/a-file: Operation not permitted The reason for this is that do_write() starts by opening the file non-truncating for writing, stat:ing it and then calling verify_write_or_copyup(). It is expecting the the open(write) to succeed, however, in the fs-verity case any open with write fails with EPERM. We fix this by delaying the EPERM failure, only reporting it when the file descriptor needs to be used. In the case this triggered a copyup the file descriptor will be reopened, and in this case we will not get the EPERM anymore. To simplify this code the fd variable now uses glnx_autofd. This fixes coreos/rpm-ostree#4827
|
Looks sane, would be good to have a new test case...I was looking at this but the existing test case is failing for me with which I haven't debugged yet. Just thinking about this though...I bet we could test your change here even if the host environment doesn't use fsverity by simply using |
|
I'll have a look at adding a test tomorrow |
|
Not sure chmod is enough, that would give a EACCESS instead of EPERM, no? Maybe some immutable attr would workj? |
|
One problem here is that we do copyup if the calling process just does e.g. |
|
Ended up trying out an alternative flow in #3175 - mind taking a look? |
|
The other approach seems fine to me too. |
In case fs-verity is in used for the repo objects, and something like "rpm-ostree apply-live" uses rofiles-fuse with --copyup, then writing to a hard-linked file fails to copy up, like this:
echo foo > /a/rofile-mnt/a-file
/a/rofile-mnt/a-file: Operation not permitted
The reason for this is that do_write() starts by opening the file non-truncating for writing, stat:ing it and then calling verify_write_or_copyup(). It is expecting the the open(write) to succeed, however, in the fs-verity case any open with write fails with EPERM.
We fix this by delaying the EPERM failure, only reporting it when the file descriptor needs to be used. In the case this triggered a copyup the file descriptor will be reopened, and in this case we will not get the EPERM anymore.
To simplify this code the fd variable now uses glnx_autofd.
This fixes coreos/rpm-ostree#4827